![]() |
Java Database Programming with JDBC
by Pratik Patel Coriolis, The Coriolis Group ISBN: 1576100561 Pub Date: 10/01/96 |
Previous | Table of Contents | Next |
Every Web browsers Java interpreter includes a security manager to determine what an applet can and cant do. For instance, the security mangager does not allow applets downloaded from remote Web pages to access the local disk; it restricts network connections attempted by the applet to only the machine from which the applet came from; and it restricts applets from gaining control of local system devices. These restrictions are in place to protect users from rogue applets (or should I say rogue applet programmers) attempting to break into your computer. The user does not need to worry about the applet formatting the hard disk or reading password files. Of course, Im simplifying the applet security scheme, but I want to point out the care that is taken to protect the user, and the restrictions that developers are faced with when programming applets. So how does this relate to the JDBC? The immediate concern for you as the developer is that your JDBC applet can only connect to the same machine that served the applet initially (i.e. your Web server). This means that you must run a Web server on the same machine as your database server. However, if you choose the application server route that we will discuss in Chapter 11, you must run the application server alongside the Web server, but then you are free to run the database server on another machine. If the user installs the applet locally and runs it, these security restrictions do not apply. But unfortunately, that defeats the purpose behind an applet: a program that comes over the network and begins running locally without installation.
To account for these tight security restrictions, the Java Commerce API addresses easing security if the applet comes from a trusted source. This means that if the Web browser recognizes as genuine the certification of the Web page, applets on the page may also be considered certified. To obtain such a status, you must apply for certification from the proper authority. When you receive certification, simply attach it to applets that are served from your Web site. The Commerce and Security APIs allow for the fetching of trusted applets, so if the user uses a Java interpreter that incorporates the Java Commerce API and Security API, you (the developer) can serve applets that can connect to an application server or database server running on a different machine than the Web server. In fact, you can even attach to different database servers simultaneously if necessary. In addition, this approach may allow the applet to save the contents of a database session on the users disk, or read data from the users disk to load previous session data.
The exact security restrictions of trusted applets are not set in stone, and they may differ depending on the Web browser the applet is run on. Also, the Java Commerce and Security specifications and related APIs have not been finalized as of the writing of this book, so much may change from the preliminary details of the security scheme by the time the APIs are released and implemented.
Security in data transactions is a top priority in the Internet community. In this chapter, weve discussed possible security holes and techniques to sew them up. We also took a look at Javasofts approach to easing security restrictions for applets that come from a certified trusted source.
In the next chapter, we jump back into the meat of the JDBC when we explore writing JDBC drivers. Well explore the heart of the JDBCs implementation details, and well also develop a real JDBC driver that can serve as the basis for drivers you write in the future.
Previous | Table of Contents | Next |